The present invention generally relates to computer software application programs for providing to other installed application programs the ability to repair missing program files. More particularly, the present invention relates to an application program or software module for verifying the existence of a program file at an expected location, and for installing the program file to that expected location if the program file is missing.
Before use, an application program must typically be installed to a computer system. The installation procedure generally involves copying executable and data files (the xe2x80x9cprogram filesxe2x80x9d) related to the application program from a source location to an installed location on the computer system. Typically, the source location is an installation disk or location on a network drive accessible by the computer system. Often the program files are stored in a compressed format to conserve storage space.
Today, application programs use a variety of installation technologies to copy the program files from the source location to the computer system. Most often, an application program will include a special application program (the xe2x80x9cset-up programxe2x80x9d) for administering and performing the installation procedure. Generally, the set-up program is unique to the application program and is customized to install the program files from the source location to pre-configured locations on the computer system. Often the user is provided the option of redirecting the installation of the program files to other locations on the computer system.
The typical set-up program not only installs the program files to the computer system, but also creates entries in a central registration database, such as a system registration database (the xe2x80x9csystem registryxe2x80x9d), which identify the locations of the program files on the computer system. The location may be identified by a xe2x80x9cpathxe2x80x9d to a particular directory or folder of the computer system in which reside the program files. The entries in the system registry are typically maintained by the application program itself. While executing, the application program generally queries the system registry for the path to an installed program file, and then accesses the installed program file at the path identified in the system registry.
Any changes to the entries in the system registry are governed by the application program.
Current installation technologies perform satisfactorily if the program files are never inadvertently deleted or moved from their installed locations. As mentioned, the start-up program creates the entries in the system registry which define the path to the installed program files. Installation technologies today do not include a mechanism for policing the installed state of the program files after installation. In addition, current installation technologies do not include the ability to verify the existence of a program file after it has been installed, for instance at run-time of the application program.
One problem plaguing software developers is the over-zealous computer user. Often, the over-zealous user, in an attempt to minimize disk space usage on the computer system, may delete a program file with which the user is unfamiliar. Likewise, the over-zealous user may attempt to rearrange the file structure of the computer system by moving the program files after installation. Unfortunately, existing installation technologies do not include the ability to identify and repair the situation where a program file is expected to be at an installed location but is no longer at that location.
Currently, when an application program queries the system registry for the path to a program file, the operating system performs a simple table look-up in the system registry and returns the path to the program file. However, no verification is performed to ensure that the program file still exists at the path originally written by the set-up program. The operating system acts as a simple database look-up engine. If a program file is inadvertently deleted, it will go undetected until needed. Consequently, the application program may attempt to launch or access the program file at the path and receives an error message indicating that the program file is unavailable.
In such a situation, the application program is typically unable to continue functioning properly and may generate an error prompting the user to execute the set-up program again to repair the missing program file. In that case, the user is forced to terminate the current process and handle the error before continuing. The normal operation of the application program is interrupted, and the user may be greatly inconvenienced until the dilemma of the missing program file is resolved.
Thus, existing installation technologies fail to support the ability to repair an application program if a requested program file becomes deleted or otherwise unavailable at the program file""s installed location. Accordingly, there is a need in the art for a system and method for installing an application program which provides the ability to efficiently resolve the situation where an installed program file becomes inadvertently unavailable to the application program. In addition, there is a need in the art for a system and method for verifying the existence of an installed program file upon an indication by the application program that the program file is needed. Moreover, there is a need in the art for a system and method for providing an application program with the ability to install a missing program file in a background process that does not terminate the application program""s current process.
The present invention meets the above-described needs by providing the ability to identify a missing program file necessary to an application program, and to install the missing program file without interrupting the operation of the application program. The present invention achieves that result by receiving an indication that a resource, such as a program file or registry key, is needed by the application program. The indication may take the form of a request for the location of the needed resource. The present invention may maintain a listing of the locations of the resources needed by the application. In response to the indication, the present invention verifies the existence of the needed resource prior to the application attempting to execute the resource. The verification may be achieved by querying for the existence of the resource at the location maintained in the listing. If the resource does not exist, the present invention initiates the installation of the resource. The installation may occur in a background process without interrupting the application program, or by prompting the application program for instructions whether to install the missing resource.
In one embodiment, when an application program is installed, an installer application stores information in a registration database (the xe2x80x9cinstaller registryxe2x80x9d) related to the locations of the application program""s resources, such as program files and registry keys. The installer registry may be a portion of the general system registry, or the installer registry may be a stand-alone registration database. A resource identifier may be assigned to each resource to uniquely identify that resource from other resources. Within the installer registry, the location of each resource may be associated with the resource identifier for that resource.
To invoke a particular xe2x80x9cfeature,xe2x80x9d the application program indicates to the installer application which feature to invoke by passing to the installer application a resource identifier for a resource needed by that feature. A xe2x80x9cfeaturexe2x80x9d is a granular piece of the product that a user may choose to install or execute. Features typically correspond roughly to the functional features of the program itself, such as a proofing tools feature or a word processing feature. Invoking the feature may constitute selecting an option from the menu, querying the installer application to identify which features of the application program are installed, or other methods for invoking the feature as will be understood by those skilled in the art.
The resource identifier passed to the installer application may take the form of a xe2x80x9ctoken,xe2x80x9d which may include one or more of the following arguments: an identifier for the application program (the xe2x80x9cProduct Codexe2x80x9d), an identifier for the invoked feature (the xe2x80x9cfeature identifierxe2x80x9d), or an identifier for a xe2x80x9ccomponentxe2x80x9d related to the resource needed by the feature (the xe2x80x9cComponent Codexe2x80x9d). A xe2x80x9ccomponentxe2x80x9d is a collection of resources, such as files, shortcuts, or registry keys, that are all installed or un-installed as a unit. Components are the building blocks of the program that are not exposed to the user. Alternatively, the resource identifier may take the form of a xe2x80x9cdescriptor,xe2x80x9d which may include similar information to the token, but formatted to be more easily interpreted by the installer application.
Again in one embodiment, passing the resource identifier may include issuing an application programming interface (xe2x80x9cAPIxe2x80x9d) call, with the resource identifier as a parameter, to the installer application in the form of a request for the location of the resource identified by the resource identifier. In response to receiving the API call, the installer application first accesses the installer registry and retrieves the location of the resource associated with the resource identifier. The installer application then verifies the existence of the resource at that location. If the resource exists at the location, the installer application returns the location to the application program. The application program then accesses the resource at the location. However, if the installer application fails to verify the existence of the resource at the location, the installer application initiates a repair procedure.
The repair procedure may take two forms. A xe2x80x9cbrute forcexe2x80x9d repair procedure may be used, generally if the application program is an operating system function or service, such as a shortcut maintained by the operating system. In that case, the installer application may automatically execute an installation procedure to install the resource. Installing the resource may include prompting a user for a xe2x80x9csourcexe2x80x9d which contains the program files for the application program, retrieving the program files from the source, and writing the program files and other resources to the appropriate location. Processing may then return to the application program by passing the location of the newly-installed resource to the application.
Another repair procedure may also be invoked, generally for conventional application programs. Rather than automatically executing the installation procedure, the installer application may return a message to the application program that the resource does not exist at the expected location. The application program may then choose from several alternatives to handle the message. For instance, the application program may prompt the user to choose whether to install the missing resource, or the application program may be pre-configured to automatically execute the installation procedure for certain missing resources. If the choice is made to install the missing resource, the application program indicates that choice to the installer application. The installer application then executes the installation procedure, in the same fashion as that described above, and the missing resource is installed.
In that manner, if a resource becomes deleted or otherwise not available at an expected location, rather than the application program being forced to quit, or execute with unstable characteristics, the absence of the missing resource is detected, and it may be installed either automatically (without user or application program input) or only if desired.